GermanWikipedia - /page/entry.mu

Micron Document

<!DOCTYPE html>

<title>Controller Area Network</title>

</head>

<h1 id="firstHeading" class="firstHeading mw-first-heading"><span class="mw-page-title-main">Controller Area Network</span></h1>

</header>

</div>

<p>Der <b>CAN-Bus</b> (<i><b>C</b>ontroller <b>A</b>rea <b>N</b>etwork</i>) ist ein serielles <a href="Bus_(Datenverarbeitung)" title="Bus (Datenverarbeitung)">Bussystem</a> und gehört zu den <a href="Feldbus" title="Feldbus">Feldbussen</a>.

</p><p>Er wurde 1983 vom Unternehmen <a href="Robert_Bosch_GmbH" title="Robert Bosch GmbH">Bosch</a> entwickelt und 1986 zusammen mit <a href="Intel" title="Intel">Intel</a> vorgestellt. Sein Zweck ist es, <a href="Kabelbaum" title="Kabelbaum">Kabelbäume</a> zu reduzieren und hiermit Kosten und Gewicht zu sparen. Zur damaligen Zeit konnte die Gesamtlänge aller Kabel in Kraftfahrzeugen beispielsweise ohne CAN bis zu 2 km betragen.

</p><p>CAN ist in <a href="ISO" class="mw-redirect" title="ISO">ISO</a> 11898-1 international standardisiert und definiert Layer 2 (Datensicherungsschicht) im <a href="ISO/OSI-Referenzmodell" class="mw-redirect" title="ISO/OSI-Referenzmodell">ISO/OSI-Referenzmodell</a>. Die beiden gängigsten Realisierungen der physischen Schichten sind nach ISO 11898-2 (Highspeed physical layer) und ISO 11898-3 (Fault tolerant physical layer) definiert. Sie unterscheiden sich in zahlreichen Eigenschaften und sind nicht zueinander kompatibel.

</p>

<div class="mw-heading mw-heading2"><h2 id="Funktion">Funktion</h2></div>

<div class="mw-heading mw-heading3"><h3 id="Übertragungsverfahren"><span id=".C3.9Cbertragungsverfahren"></span>Übertragungsverfahren</h3></div>

<p>Der CAN-Bus arbeitet nach dem „Multi-Master-Prinzip“, d. h. er verbindet mehrere gleichberechtigte Steuergeräte. Ein <a href="Carrier_Sense_Multiple_Access/Collision_Resolution" title="Carrier Sense Multiple Access/Collision Resolution">CSMA/CR</a>-Verfahren löst Kollisionen (gleichzeitiger Buszugriff) auf, ohne dass die gewinnende, höher <a href="Priorit%C3%A4t" title="Priorität">priorisierte</a> Nachricht beschädigt wird. Dazu sind die Bits – je nach Zustand – <i>dominant</i> bzw. <i>rezessiv</i> (ein dominantes Bit überschreibt ein rezessives). Die logische 1 ist rezessiv, kann sich auf dem Bus also nur durchsetzen, solange kein Teilnehmer logisch 0 sendet, logisch entspricht dies einer <a href="Konjunktion_(Logik)" title="Konjunktion (Logik)">UND-Verknüpfung</a>, obwohl bei Betrachtung einer der Leitungen für die Spannungspegel eine <a href="Wired-OR-Verkn%C3%BCpfung" class="mw-redirect" title="Wired-OR-Verknüpfung">Wired-OR-Verknüpfung</a> gilt. Die Daten sind <a href="Non_Return_to_Zero" title="Non Return to Zero">NRZ</a>-codiert, mit <a href="Bitstopfen" title="Bitstopfen">Bitstopfen</a> zur fortlaufenden Synchronisierung auch von Busteilnehmern mit wenig stabilem <a href="Oszillator" title="Oszillator">Oszillator</a>. Zur Erhöhung der Übertragungssicherheit wird die <a href="Zyklische_Redundanzpr%C3%BCfung" title="Zyklische Redundanzprüfung">zyklische Redundanzprüfung</a> eingesetzt.

</p>

<p>Im Falle von Kupferleitungen arbeitet der CAN-Bus mit zwei <a href="Verdrillung" class="mw-redirect" title="Verdrillung">verdrillten</a> Adern, CAN_HIGH (CAN_H) und CAN_LOW (CAN_L) (<a href="Symmetrische_Signal%C3%BCbertragung" title="Symmetrische Signalübertragung">symmetrische Signalübertragung</a>). CAN_GND (Masse) als dritte Ader ist optional, jedoch oft zusammen mit einer vierten Ader zur 5-V-Stromversorgung vorhanden.

</p><p>Bei höheren Datenraten (Highspeed-CAN) ist der Spannungshub zwischen den beiden Zuständen relativ gering: Im rezessiven Ruhezustand ist die Differenzspannung null (beide Adern etwa 2,5 V über Masse), im dominanten Zustand beträgt sie mindestens 2 V (CAN_HIGH > 3,5 V, CAN_LOW < 1,5 V).

</p><p>Beim für größere Distanzen geeigneten Lowspeed-CAN kommt ein Spannungshub von 5 V zum Einsatz, indem die rezessiven Ruhepegel auf 5 V (CAN_LOW) und 0 V (CAN_HIGH) gelegt sind. Bei Ausfall einer der beiden Leitungen kann die Spannung der anderen Leitung gegen Masse ausgewertet werden. Bei langsameren Bussen („Komfort-Bus“ z. B. zur Betätigung von Elementen durch den Benutzer) kann ein Eindrahtsystem mit der Karosserie als Masse deshalb reichen. Praktisch wird es meistens doch als Zweidrahtsystem ausgeführt, verwendet aber im Fall eines Aderbruchs den Eindrahtbetrieb als Rückfallebene, um den Betrieb weiterführen zu können. Das nennt sich dann „Limp-Home-Modus“ (Deutsch: „nach-Hause-humpeln-Modus“).

</p>

<div class="mw-heading mw-heading3"><h3 id="Topologie">Topologie</h3></div>

<p>Das CAN-Netzwerk wird als Linienstruktur aufgebaut. <a href="Stichleitung" title="Stichleitung">Stichleitungen</a> sind in eingeschränktem Umfang zulässig, auch ein sternförmiger Bus (z. B. bei der Zentralverriegelung im Auto) ist möglich. Diese Varianten haben allerdings im Vergleich zum linienförmigen Bus Nachteile:

</p><ul><li>Der sternförmige Bus wird meist von einem Zentralrechner gesteuert, da diesen alle Informationen passieren müssen, mit der Folge, dass bei einem Ausfall des Zentralrechners keine Informationen weitergeleitet werden können. Beim Ausfall eines einzelnen Steuergeräts funktioniert der Bus weiter.</li>

<li>Für Stichleitungen und sternförmige Busarchitektur ist der <a href="Leitungswellenwiderstand" class="mw-redirect" title="Leitungswellenwiderstand">Leitungswellenwiderstand</a> etwas aufwendiger zu bestimmen. Die Anzahl der Stichleitungen und ihre Gesamtlänge wird durch empirische Richtformeln abgeschätzt. Der lineare Bus hat den Vorteil, dass alle Steuergeräte parallel an einer zentralen Leitung liegen. Nur wenn diese ausfällt, funktioniert der Bus nicht mehr. Diese Topologie wird häufig in Kraftfahrzeugen eingesetzt.</li></ul>

<p>An jedem Leitungsende sollte sich je ein <a href="Abschlusswiderstand" class="mw-redirect" title="Abschlusswiderstand">Abschlusswiderstand</a> von 120 Ohm befinden. Für einen einzelnen CAN-Bus-Teilnehmer an einer Stichleitung wirkt dies genauso wie ein einzelner 60-Ohm-Widerstand, der am Ort der Abzweigung eingefügt ist. Dieser Wert ist die zentrale Impedanz einer Sternarchitektur.

</p>

<div class="mw-heading mw-heading3"><h3 id="Synchronisierung_und_Zeitquanten">Synchronisierung und Zeitquanten</h3></div>

<p>Die nominale <a href="Daten%C3%BCbertragungsrate" title="Datenübertragungsrate">Datenübertragungsrate</a> im Netzwerk muss allen Teilnehmern bekannt sein, ggf. durch automatische Detektion – <a href="CAN_in_Automation" title="CAN in Automation">CAN in Automation</a> hat dazu eine Application-Note herausgegeben, CiA 801. Die Synchronisation auf den genauen Beginn einer Nachricht erfolgt mit dem Wechsel vom rezessiven Idle-Pegel des Busses zum dominanten Synchronisations-Bit, mit dem jede Nachricht beginnt. Jeder weitere Pegelwechsel von rezessiv zu dominant kann zur dynamischen Nachsynchronisierung der Empfänger verwendet werden. Die Nachsynchronisierung gleicht Phasenrauschen und -drift zwischen den lokalen Oszillatoren aus. Eine Nachsynchronisierung findet auch während der Arbitrierungsphase statt, wenn ein Sender eine Nachricht mit höherer Priorität zu senden beginnt. Dies bewirkt meist ebenfalls einen Phasensprung in Bezug zur vorherigen Nachricht.

</p>

<div class="mw-heading mw-heading3"><h3 id="Maximale_Übertragungsrate_und_Leitungslänge"><span id="Maximale_.C3.9Cbertragungsrate_und_Leitungsl.C3.A4nge"></span>Maximale Übertragungsrate und Leitungslänge</h3></div>

<p>Es wird zwischen einem Highspeed-Bus mit einer Datenrate von bis zu 1 Mbit/s und einem Lowspeed-Bus mit bis zu 125 kbit/s unterschieden. Diese Raten gelten jedoch nur bei Leitungslängen bis zu 40 m. Darüber hängt die maximal zulässige Datenrate von der Leitungslänge ab. Mit niedrigeren Datenraten sind längere Leitungen möglich: bei 500 kbit/s bis zu 100 m und bei 125 kbit/s bis zu 500 m.

</p><p>Diese Maximalwerte beruhen darauf, dass die Zeit, die ein Signal am Bus anliegt (Bitzeit, Sekunde/Bit), umso kürzer ist, je höher die Übertragungsrate ist. Mit zunehmender Leitungslänge steigt jedoch die Zeit, die ein Signal braucht, bis es am anderen Ende des Busses angekommen ist (<a href="Ausbreitungsgeschwindigkeit" class="mw-redirect" title="Ausbreitungsgeschwindigkeit">Ausbreitungsgeschwindigkeit</a>). Zu beachten ist, dass sich das Signal nicht nur ausbreitet, sondern der Empfänger auch innerhalb einer begrenzten Zeit auf den Sender reagieren muss (siehe ACK). Der Sender muss wiederum die eventuelle Buspegeländerung des oder der Empfänger mitbekommen (siehe auch Arbitrierung). Deshalb ist die maximale Leitungslänge etwas komplexer zu berechnen. Es müssen Verzögerungszeiten auf der Leitung, des Transceivers (Sender und Empfänger), des Controllers (Sender und Empfänger), Oszillatortoleranzen und der gesetzte Abtastzeitpunkt (Sender und Empfänger) berücksichtigt werden.

</p><p>Der weiterentwickelte CAN‑FD‑Standard (FD steht für engl. <i>flexible data rate</i>) erlaubt es, die Datenrate nach der Verbindungsaushandlung zu erhöhen. Damit kann die Übertragungsgeschwindigkeit des Datenabschnitts um den Faktor 10 oder mehr gesteigert werden.

</p><p>Als Busmedium werden nach <a href="International_Organization_for_Standardization" class="mw-redirect" title="International Organization for Standardization">ISO</a> 11898-2 (High-Speed Medium Access Unit) <a href="Twisted-Pair-Kabel" title="Twisted-Pair-Kabel">Twisted-Pair-Kabel</a> ursprünglich mit einem <a href="Wellenimpedanz" class="mw-redirect" title="Wellenimpedanz">Wellenwiderstand</a> von 108–132 <a href="Ohm_(Einheit)" class="mw-redirect" title="Ohm (Einheit)">Ohm</a> empfohlen.

In der derzeit gültigen Ausgabe der ISO 11898-2 aus dem Jahr 2016 ist die Toleranz der Abschlusswiderstände, die an beiden Enden angeschlossen werden müssen, mit 100–130 Ohm angegeben.

</p><p>Die maximale Teilnehmeranzahl auf physischer Ebene hängt von den verwendeten Bustreiberbausteinen (Transceiver, physische Anschaltung an den Bus) ab. Mit gängigen Bausteinen sind 32, 64 oder bis zu 110 (mit Einschränkungen bis zu 128) Teilnehmer pro Leitung möglich (Erweiterungsmöglichkeit über Repeater oder Bridge).

</p>

<div class="mw-heading mw-heading3"><h3 id="Objekt-Identifier">Objekt-Identifier</h3></div>

<p>Der Objekt-Identifier kennzeichnet den Inhalt der Nachricht, nicht das Gerät. Zum Beispiel kann in einem Messsystem den Parametern Temperatur, Spannung und Druck jeweils ein eigener Identifier zugewiesen sein. Es können mehrere Parameter unter einem Identifier vereint sein, solange die Summe der Daten die maximal mögliche Länge des Datenfeldes nicht überschreitet. Die Empfänger entscheiden anhand des Identifiers, ob die Nachricht für sie relevant ist oder nicht.

</p><p>Zudem dient der Objekt-Identifier auch der Priorisierung der Nachrichten.

</p><p>Die Spezifikation definiert zwei Identifier-Formate:

</p>

<ul><li>11-Bit-Identifier, auch „Base frame format“ genannt (CAN 2.0A)</li>

<li>29-Bit-Identifier, auch „Extended frame format“ genannt (CAN 2.0B).</li></ul>

<p>Ein Teilnehmer kann Empfänger und Sender von Nachrichten mit beliebig vielen Identifiern sein, aber umgekehrt darf es zu einem Identifier immer nur maximal einen Sender geben, damit die <a href="Arbitrierung" class="mw-redirect" title="Arbitrierung">Arbitrierung</a> funktioniert.

</p><p>Der 29-Bit-Identifier ist in erster Linie für das Umfeld von Nutzfahrzeugen, Schiffen, Schienenfahrzeugen und Landmaschinen definiert.

Der CAN-Standard fordert, dass eine Implementierung das „Base frame format“ akzeptieren muss, dagegen das „Extended frame format“ akzeptieren kann, es aber zumindest tolerieren muss.

</p><p>Die Liste der Objekt-Identifier einschließlich Sender und Empfänger ist Bestandteil der sog. <i>Kommunikationsmatrix</i> oder <i>K-Matrix</i>.

</p>

<div class="mw-heading mw-heading3"><h3 id="Arbitrierung,_Priorität"><span id="Arbitrierung.2C_Priorit.C3.A4t"></span>Arbitrierung, Priorität</h3></div>

<p>Der Buszugriff wird verlustfrei mittels der bitweisen <a href="Arbitrierung" class="mw-redirect" title="Arbitrierung">Arbitrierung</a> auf Basis der Identifier der zu sendenden Nachrichten aufgelöst. Dazu überwacht jeder Sender den Bus, während er gerade den Identifier sendet. Senden zwei Teilnehmer gleichzeitig, so überschreibt das erste dominante Bit eines der beiden das entsprechend rezessive des anderen, was dieser erkennt und seinen Übertragungsversuch beendet. Verwenden beide Teilnehmer den gleichen Identifier, wird nicht sofort ein Error-Frame erzeugt (siehe Frame-Aufbau), sondern erst bei einer Kollision innerhalb der restlichen Bits, was durch die Arbitrierung ausgeschlossen sein sollte. Daher empfiehlt der Standard, dass ein Identifier auch nur von maximal einem Teilnehmer verwendet werden soll.

</p><p>Durch dieses Verfahren ist auch eine Hierarchie der Nachrichten untereinander gegeben. Die Nachricht mit dem niedrigsten Identifier darf immer übertragen werden. Für die Übertragung von zeitkritischen Nachrichten kann also ein Identifier hoher Priorität (= niedrige ID, z. B. 0x001; 0x000 für Netzmanagement – NMT) vergeben werden, um ihnen so Vorrang bei der Übertragung zu gewähren. Dennoch kann selbst bei hochprioren Botschaften der Sendezeitpunkt zeitlich nicht genau vorherbestimmt werden, da gerade in Übertragung befindliche Nachrichten nicht unterbrochen werden können und den Startzeitpunkt einer Sendung so bis zur maximalen Nachrichtenlänge verzögern können (<a href="Determinismus_(Algorithmus)" title="Determinismus (Algorithmus)">nichtdeterministisches Verhalten</a>). Lediglich die maximale Sendeverzögerung für die höchstpriore Nachricht kann bei bekannter maximaler Nachrichtenlänge errechnet werden. Für niederpriore Nachrichten ist im Allgemeinen keine Aussage über den Sendezeitpunkt möglich.

</p><p>Sollte ein Teilnehmer kontinuierlich Nachrichten mit einer hohen Priorität versenden, kann dies zur Blockade des Busses führen, da die Nachrichten der anderen Teilnehmer jeweils die Arbitrierung verlieren. Dieses Verhalten wird als <a href="Babbling_idiot" title="Babbling idiot">Babbling idiot</a> beschrieben. Sollte dieses Verhalten auf einer Fehlfunktion basieren, kann es nur durch zusätzliche Hardware – sogenannte Buswächter (Bus Guardians) – gelöst werden.<sup id="cite_ref-1" class="reference"><a href="#cite_note-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading2"><h2 id="Frame-Aufbau">Frame-Aufbau</h2></div>

<p>Die Kommunikation erfolgt mit Telegrammen. Innerhalb eines Telegramms gibt es Steuerbits und Nutzbits (roter Bereich). Der genormte Aufbau eines solchen Telegrammrahmens wird als Frame bezeichnet.

</p><p>Es gibt vier verschiedene Arten von Frames:

</p>

<ul><li>Daten-Frame, dient dem Transport von Daten</li>

<li>Remote-Frame, dient der Anforderung eines Daten-Frames von einem anderen Teilnehmer</li>

<li>Error-Frame, signalisiert allen Teilnehmern eine erkannte Fehlerbedingung in der Übertragung</li>

<li>Overload-Frame, dient als Zwangspause zwischen Daten- und Remote-Frames</li></ul>

<div class="mw-heading mw-heading3"><h3 id="Daten-Frame">Daten-Frame</h3></div>

<p>Ein Daten-Frame ist logisch wie folgt aufgebaut:

</p>

<ul><li>Start of Frame (SOF) = ein dominantes Bit</li>

<li>Arbitrierungsfeld, bestehend aus einem Identifier-Segment (11 Bit oder 29+2 Bit) plus einem RTR-Bit (Remote Transmission Request, siehe unten)</li>

<li>Steuerungsfeld (CTRL) = 6 Bit

<ul><li>Identifier Extension (IDE) = 1 Bit</li>

<li>reserved = 1 Bit</li>

<li>Data Length Code (DLC) = 4 Bit (Anzahl der Bytes im Datenfeld, 0 bis 8 Bytes, Werte 9 bis 15 werden nicht unterstützt)</li></ul></li>

<li>Datenfeld (DATA) = 0 bis 8 mal 8 Bit</li>

<li>Prüfsummenfeld (<a href="Zyklische_Redundanzpr%C3%BCfung" title="Zyklische Redundanzprüfung">CRC</a>) = 15 Bit (<a href="Generatorpolynom" class="mw-redirect" title="Generatorpolynom">Generatorpolynom</a> <span class="mwe-math-element mwe-math-element-inline"><span class="mwe-math-mathml-inline mwe-math-mathml-a11y" style="display: none;"><math xmlns="http://www.w3.org/1998/Math/MathML" alttext="{\displaystyle x^{15}+x^{14}+x^{10}+x^{8}+x^{7}+x^{4}+x^{3}+1}">

<msup>

</mrow>

</msup>

<msup>

</mrow>

</msup>

<msup>

</mrow>

</msup>

<msup>

</mrow>

</msup>

<msup>

</mrow>

</msup>

<msup>

</mrow>

</msup>

<msup>

</mrow>

</msup>

</mstyle>

</mrow>

<annotation encoding="application/x-tex">{\displaystyle x^{15}+x^{14}+x^{10}+x^{8}+x^{7}+x^{4}+x^{3}+1}</annotation>

</semantics>

</math></span><img src="./_assets_/eb734a37dd21ce173a46342d1cc64c92/e57a2eb666033ffb6105bd2efd1eb606d501f6a3.svg" class="mwe-math-fallback-image-inline mw-invert skin-invert" aria-hidden="true" style="vertical-align: -0.505ex; width:40.199ex; height:2.843ex;" alt="{\displaystyle x^{15}+x^{14}+x^{10}+x^{8}+x^{7}+x^{4}+x^{3}+1}" loading="lazy"></span>) gefolgt von einem rezessiven CRC-Delimiter-Bit</li>

<li>Bestätigungsfeld (ACK) = 2 Bit, bestehend aus einem ACK-Slot (siehe untenstehende Erläuterung) plus einem rezessiven ACK-Delimiter</li>

<li>End of Frame (EOF) = 7 Bit (rezessiv)</li>

<li>Intermission (IFS – Intermission Frame Space) = 3 Bit (= min. Anzahl der Bits, die aufeinanderfolgende Botschaften trennt)</li></ul>

<div class="mw-heading mw-heading3"><h3 id="Remote-Frame">Remote-Frame</h3></div>

<p>Ein gesetztes RTR-Bit (Remote Transmission Request) kennzeichnet einen Remote-Frame (rezessiv).

Mit Hilfe eines Remote-Frames kann ein Teilnehmer einen anderen auffordern, seine Daten zu senden.

</p><p>Im Falle eines „Extended Identifiers“ (siehe oben) wird das RTR-Bit durch das SRR-Bit (Substitute Remote Request) ersetzt und ebenfalls rezessiv gesendet. In diesem Fall wird das nachfolgende IDE-Bit ebenfalls rezessiv gesendet, wodurch ein „Extended Identifier“ signalisiert wird. Im Anschluss werden die restlichen 18 Bit des Identifiers und anschließend das eigentliche RTR-Bit gesendet. Das IDE-Bit zählt dabei logisch zum „Arbitrierungsfeld“, wobei das Steuerungsfeld aber weiterhin aus 6 Bit besteht.

</p><p>Die Datenlänge muss entsprechend der zu erwartenden Datenlänge gesetzt werden (Fehlerquelle: Viele Entwickler setzen die Datenlänge = 0 – dies ist falsch; ebenso sind CAN-Controller am Markt, welche RTR-Frames nur mit der Datenlänge 0 senden können). Der Objektidentifier ist derselbe wie der der angeforderten Nachricht.

</p>

<div class="mw-heading mw-heading3"><h3 id="Error-Frame">Error-Frame</h3></div>

<p>Der Error-Frame besteht aus zwei Feldern:

</p><p>Das erste Feld wird bestimmt durch die Überlagerung von ERROR FLAGS, die von den verschiedenen Stationen erzeugt werden können.<br>

Das folgende Feld ist der ERROR DELIMITER (8 rezessive Bits).

</p><p>Es gibt zwei Typen von <i>Error Flags</i>:

</p>

<dl><dt>Active Error Flag</dt>

<dd>6 dominante Bits, gesendet von einem Knoten, der einen Fehler im Netzwerk entdeckt hat und im Fehler-Status „error active“ ist.</dd>

<dt>Passive Error Flag</dt>

<dd>6 rezessive Bits, gesendet von einem Knoten, der einen Fehler im Netzwerk entdeckt hat und im Fehler-Status „error passive“ ist.</dd></dl>

<div class="mw-heading mw-heading3"><h3 id="Overload-Frame">Overload-Frame</h3></div>

<p>Der Overload-Frame ist eine Zwangspause zwischen Daten- und Remote-Frames.<br>

Er beinhaltet zwei Felder: Overload Flag und Overload Delimiter.

</p><p>Es gibt zwei Arten von Überlastung, die zur Generierung des Overload-Flag führen:

</p>

<ol><li>Die Elektronik des Empfängers erfordert eine Verzögerung der Übertragung des nächsten Datenframes oder Remoteframes (bspw. aufgrund eines vollen Empfangspuffers).</li>

<li>Erkennung eines dominanten Bits auf dem Bus während einer Übertragungspause des eigenen Sendevorganges.</li></ol>

<p>Ein Overload-Frame, verursacht aufgrund des ersten Falls, darf nur im ersten Bitintervall einer erwarteten Sendepause erzeugt werden, während ein Overload-Frame, bedingt durch Fall 2, einen Takt nach der Erkennung des dominanten Bits gesendet wird.

</p>

<ul><li>Das Overload-Flag besteht aus sechs dominanten Bits.</li>

<li>Die allgemeine Form korrespondiert zu der des Active-Error-Flags: Die Form des Overload-Flags zerstört die festgelegte Übertragungsform, da das Bitstuffing verletzt wird. Als Konsequenz erkennen alle anderen Geräte ebenfalls die Überlastung und generieren selber wiederum auch ein Overload-Flag.</li>

<li>Der Overload-Delimiter besteht aus acht rezessiven Bits und entspricht der Form des Error-Delimiters.</li></ul>

<p>Der Acknowledge-Slot wird verwendet, um den Empfang eines korrekten CAN-Frames zu quittieren. Jeder Empfänger, der keinen Fehler feststellen konnte, setzt einen dominanten Pegel an der Stelle des ACK-Slots und überschreibt somit den rezessiven Pegel des Senders. Im Falle einer negativen Quittung (rezessiver Pegel) muss der fehlererkennende Knoten nach dem ACK-Delimiter ein Error-Flag auflegen, damit erstens der Sender vom Übertragungsfehler in Kenntnis gesetzt wird und zweitens, um netzweite Datenkonsistenz sicherzustellen. Wird der rezessive Pegel von einem Empfänger durch einen dominanten überschrieben, kann der Absender jedoch nicht davon ausgehen, dass das Telegramm von allen anderen Empfängern erhalten wurde.

</p>

<div class="mw-heading mw-heading2"><h2 id="Bit_Stuffing">Bit Stuffing</h2></div>

<p>Bitfolgen mit mehr als fünf gleichen Bits werden im CAN-Protokoll für Steuerungszwecke z. B. „End of Frame“ benutzt. Es dürfen also innerhalb des CAN-Frames nicht mehr als fünf Bits mit dem gleichen Pegel hintereinander vorkommen. Um dies zu verhindern, wird nach fünf Bits mit dem gleichen Pegel ein Bit mit dem inversen Pegel eingefügt. Dieses Bit nennt man „Stopf-Bit“ oder „stuff bit“. Im Bild (oben) sind die Stopfbits lila eingefärbt. <a href="Bitstopfen" title="Bitstopfen">Bitstopfen</a> (<i>bit stuffing</i>) kann die physische Länge eines Frames vergrößern. Bit stuffing wirkt auf Start of frame (SOF) bis einschließlich Prüfsummenfeld (CRC) von Daten- sowie Remote-Frames und dient der Nachsynchronisation der Teilnehmer innerhalb eines Frames.

</p>

<div class="mw-heading mw-heading2"><h2 id="Datensicherung">Datensicherung</h2></div>

<p>Erkennt ein Empfänger eine Fehlerbedingung, sendet er einen Error-Frame und veranlasst so alle Teilnehmer, den Frame zu verwerfen. Sollten andere Teilnehmer diese Fehlerbedingung erkannt haben, senden sie ihrerseits direkt im Anschluss ein weiteres Error-Frame. Damit wird eine weitere Sicherheitsfunktion des CAN-Protokolls möglich. Um zu vermeiden, dass einzelne Teilnehmer durch irrtümlich erkannte Fehlerbedingungen dauerhaft den Nachrichtentransport blockieren, enthält jeder Teilnehmer Fehlerzähler. Diese Zähler erlauben nach den Regeln der Spezifikation, einen fehlerhaft arbeitenden Teilnehmer in zwei Stufen des Betriebszustands vom Bus zu trennen, wenn er wiederholt Fehler erkennt, die andere Teilnehmer nicht erkennen, oder wiederholt fehlerhafte Frames versendet. Die Zustände nennen sich <i>error active</i> (normal), <i>error passive</i> (Teilnehmer darf nur noch passive – das heißt rezessive – Error-Frames senden) und <i>bus off</i> (Teilnehmer darf nicht mehr senden).

</p><p>Der Sender wiederholt nach dem Error-Frame seine Datenübertragung. Auch der Sender kann durch die zuvor erwähnten Fehlerzähler vom Bus getrennt werden, wenn die Datenübertragung dauerhaft fehlschlägt. Verschiedene Fehlerfälle führen zu einer unterschiedlich großen Erhöhung des Fehlerzählers.

</p>

<div class="mw-heading mw-heading2"><h2 id="Bit-Timing">Bit-Timing</h2></div>

<p>Alle CAN-Knoten müssen mit derselben Bitrate arbeiten, was aufgrund von technischen Gegebenheiten, wie Phasenverschiebungen durch Laufzeiten, Unterschiede in den Taktraten der einzelnen Oszillatoren und anderen äußeren Einwirkungen erschwert wird.<sup id="cite_ref-2" class="reference"><a href="#cite_note-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup> Da kein allgemeiner Taktgeber vorhanden ist, müssen sich die einzelnen Knoten selber synchronisieren. Die Synchronisation ist wichtig, damit die Knoten sowohl die eigenen gesendeten Daten, als auch empfangene Daten korrekt einlesen können. Sind sie nicht synchronisiert kann es zu ungewollten Busfehlern kommen.

</p><p>

Die Synchronisierung beginnt mit einer Synchronisierung beim ersten rezessiv-zu-dominanten Übergang nach einem Inter Frame Space (dem Startbit). Eine Resynchronisation erfolgt bei jedem rezessiv-zu-dominanten Übergang während des Frames. Der CAN-Controller erwartet, dass der Übergang zu einem Vielfachen der nominalen Bitzeit erfolgt. Ist dies nicht der Fall, passt er die nominale Bitzeit entsprechend an.</p>

<p>Die Anzahl an verwendeten Quanten kann auf dem Mikrocontroller selber konfiguriert werden. Sie hängt ab von der tatsächlichen Bitrate und Qualität des Netzwerkes.

</p><p>Kommt ein Bitwechsel früher oder später als erwartet, kann der CAN-Controller die Differenz berechnen und die Länge der Phasensegmente 1 und 2 verlängern oder verkürzen. Eine Resynchronisierung wird bei jedem rezessiv-zu-dominanten Bitwechsel durchgeführt, damit Empfänger und Sender synchron bleiben. Dies hat eine verringerte Störanfälligkeit durch Rauschen zur Folge. Ein Knoten, der die Synchronisierung verloren hat, kann sich somit jederzeit selber synchronisieren.

</p>

<div class="mw-heading mw-heading2"><h2 id="Security">Security</h2></div>

<p>Das CAN-Protokoll unterstützt standardmäßig keine Sicherheitsfunktionen. Die Botschaften auf dem Bus werden ohne Verschlüsselung übertragen und sind für jeden Busteilnehmer einsehbar. Schon jetzt sind diverse Angriffe auf CAN-Bus-Systeme bekannt, unter anderem:<sup id="cite_ref-:0_3-0" class="reference"><a href="#cite_note-:0-3"><span class="cite-bracket">[</span>3<span class="cite-bracket">]</span></a></sup>

</p>

<ul><li>Bus Flood Attack</li>

<li>Simple Frame Spoofing</li>

<li>Adaptive Spoofing</li>

<li>Error Passive Spoofing Attack</li>

<li>Double Receive Attack</li>

<li>Bus-Off Attack</li>

<li>Freeze Doom Loop Attack</li></ul>

<p>Obwohl einige Systeme zwar unabhängig des Kommunikationsmediums geschützt sind (z. B. über <a href="Challenge-Response-Authentifizierung" title="Challenge-Response-Authentifizierung">Challenge Response</a> Sicherheitsverfahren), zeigt ein Jeep-Hack aus dem Jahre 2015, dass Angriffe auf den CAN-Bus durchaus gravierende Folgen haben können.<sup id="cite_ref-:1_4-0" class="reference"><a href="#cite_note-:1-4"><span class="cite-bracket">[</span>4<span class="cite-bracket">]</span></a></sup>

</p><p>Analysiert man den CAN-Bus hinsichtlich der gängigsten Sicherheitsziele, lassen sich einige Schwachstellen erkennen:

</p>

<ul><li><b><a href="Vertraulichkeit" title="Vertraulichkeit">Vertraulichkeit</a>:</b> Der CAN-Bus bietet keine Vertraulichkeit, da Botschaften im Klartext übertragen werden.<sup id="cite_ref-:2_5-0" class="reference"><a href="#cite_note-:2-5"><span class="cite-bracket">[</span>5<span class="cite-bracket">]</span></a></sup></li>

<li><b>Integrität:</b> Eine gewisse Integrität wird über den Cycle Redundancy Check zwar gewährleistet, diesen kann ein Angreifer allerdings auch ohne Probleme ändern. Daher ist sie ebenfalls nicht gewährleistet.<sup id="cite_ref-:2_5-1" class="reference"><a href="#cite_note-:2-5"><span class="cite-bracket">[</span>5<span class="cite-bracket">]</span></a></sup></li>

<li><b><a href="Verf%C3%BCgbarkeit" title="Verfügbarkeit">Verfügbarkeit</a>:</b> Da das Arbitrierungsverfahren auf Prioritäten der einzelnen Nachrichten setzt, kann es vorkommen, dass eine niederpriore Nachricht nicht gesendet werden kann. Auch dieses Sicherheitsziel ist nicht gewährleistet.<sup id="cite_ref-:2_5-2" class="reference"><a href="#cite_note-:2-5"><span class="cite-bracket">[</span>5<span class="cite-bracket">]</span></a></sup></li>

<li><b><a href="Authentizit%C3%A4t" title="Authentizität">Authentizität</a>:</b> Ähnlich der Verfügbarkeit, gibt es hier ebenfalls ein Feld (Identifier), welches in der Theorie eine Authentizität bietet, allerdings kann diese durch einen Angreifer einfach geändert werden.<sup id="cite_ref-:0_3-1" class="reference"><a href="#cite_note-:0-3"><span class="cite-bracket">[</span>3<span class="cite-bracket">]</span></a></sup></li>

<li><b><a href="Verbindlichkeit" title="Verbindlichkeit">Verbindlichkeit</a>:</b> Sobald eine Nachricht empfangen wird, landet sie im Empfangspuffer des Empfängers. Beim Empfang einer weiteren Nachricht wird dieser überschrieben und ist nicht mehr vorhanden. Der Empfang dieser Botschaft kann somit abgestritten werden.<sup id="cite_ref-:1_4-1" class="reference"><a href="#cite_note-:1-4"><span class="cite-bracket">[</span>4<span class="cite-bracket">]</span></a></sup></li></ul>

<p>Keines der fünf gängigen Sicherheitsziele kann also durch den CAN-Bus erfüllt werden.

</p>

<div class="mw-heading mw-heading2"><h2 id="Standards">Standards</h2></div>

<ul><li>ISO 11898-1:2015 Road vehicles — Controller area network — Part 1: Data link layer and physical signalling</li>

<li>ISO 11898-2:2016 Road vehicles — Controller area network — Part 2: High-speed medium access unit</li>

<li>ISO 11898-3:2006 Road vehicles — Controller area network — Part 3: Low-speed, fault-tolerant, medium dependent interface</li>

<li>ISO 11898-4:2004 Road vehicles — Controller area network — Part 4: Time-triggered communication</li>

<li>ISO 11898-5:2007 Road vehicles — Controller area network — Part 5: High-speed medium access unit with low-power mode</li>

<li>ISO 11898-6:2013 Road vehicles — Controller area network — Part 6: High-speed medium access unit with selective wake-up functionality</li>

<li>SAE J2284-1:2016 High Speed CAN for Vehicle Applications at 125 kbps</li>

<li>SAE J2284-2:2016 High Speed CAN for Vehicle Applications at 250 kbps</li>

<li>SAE J2284-3:2016 High Speed CAN for Vehicle Applications at 500 kbps</li>

<li>SAE J2284-4:2016 High Speed CAN for Vehicle Applications at 500 kbps with CAN FD Data at 2 Mbps</li>

<li>SAE J2284-5:2016 High Speed CAN for Vehicle Applications at 500 kbps with CAN FD Data at 5 Mbps</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Weiterentwicklung">Weiterentwicklung</h2></div>

<p>2012 wurde von <a href="Robert_Bosch_GmbH" title="Robert Bosch GmbH">Bosch</a> ein Vorschlag zur Erhöhung der verfügbaren Bandbreite namens CAN FD (Flexible Data Rate) vorgestellt.<sup id="cite_ref-6" class="reference"><a href="#cite_note-6"><span class="cite-bracket">[</span>6<span class="cite-bracket">]</span></a></sup> Dies wird durch Verkürzung der Bit-Zeiten in der Datenphase und Vergrößerung des Datenfeldes auf bis zu 64 Byte erreicht. Insgesamt verspricht man sich zurzeit durch das „improved CAN“<sup id="cite_ref-7" class="reference"><a href="#cite_note-7"><span class="cite-bracket">[</span>7<span class="cite-bracket">]</span></a></sup> genannte Verfahren einen bis zu 8-fach höheren Datendurchsatz. Das CAN-FD-Protokoll kann wie das Classical-CAN-Protokoll alle einfachen (single) Bitfehler erkennen. Außerdem werden mehrfache (multiple) Bitfehler mit einer noch höheren Wahrscheinlichkeit entdeckt.

</p><p>CAN FD wurde international normiert und ist nun Bestandteil von ISO 11898-1:2015.

</p><p>Im <a href="Volkswagen_AG" title="Volkswagen AG">Volkswagen-Konzern</a> wurde der CAN-FD erstmals in den Fahrzeugen des <a href="Modularer_Querbaukasten#MQB_evo" title="Modularer Querbaukasten">MQB-Baukastens ab 2019</a> eingesetzt.

</p>

<div class="mw-heading mw-heading2"><h2 id="Anwendungsbereiche">Anwendungsbereiche</h2></div>

<p>CAN-Protokolle haben sich in verschiedenen, vor allem sicherheitsrelevanten Bereichen etabliert, bei denen es auf hohe Datensicherheit ankommt. Beispiele:

</p>

<ul><li><a href="Automobilindustrie" title="Automobilindustrie">Automobilindustrie</a> (Vernetzung unterschiedlicher Steuergeräte, Sensoreinheiten und Multimediaeinheiten)</li>

<li><a href="Automatisierungstechnik" title="Automatisierungstechnik">Automatisierungstechnik</a> (zeitkritische Sensoren im Feld, Überwachungstechnische Einrichtungen)</li>

<li><a href="Aufzugsanlage" title="Aufzugsanlage">Aufzugsanlagen</a> (Vernetzung der Steuerung mit verschiedenen Sensoren, Aktoren und Aufzugsanlagen untereinander innerhalb einer Aufzugsgruppe)</li>

<li><a href="Medizintechnik" title="Medizintechnik">Medizintechnik</a> (Magnetresonanz- und Computertomographen, Blutgewinnungsmaschinen, Laborgeräte, Elektro-Rollstühle, Herzlungen-Maschinen)<sup id="cite_ref-8" class="reference"><a href="#cite_note-8"><span class="cite-bracket">[</span>8<span class="cite-bracket">]</span></a></sup></li>

<li><a href="Flugzeugtechnik" class="mw-redirect" title="Flugzeugtechnik">Flugzeugtechnik</a> (Vernetzung innerhalb von Kabinen- und Flugführungssystemen)</li>

<li><a href="Raumfahrttechnik" class="mw-redirect" title="Raumfahrttechnik">Raumfahrttechnik</a> (vermehrte Verwendung in parallelen Busarchitekturen)</li>

<li><a href="Beschallungsanlage" title="Beschallungsanlage">Beschallungsanlage</a> (wird für die Steuerung von digitalen Endstufen verwendet)</li>

<li><a href="Schienenfahrzeuge" class="mw-redirect" title="Schienenfahrzeuge">Schienenfahrzeuge</a></li>

<li><a href="Schiffbau" title="Schiffbau">Schiffbau</a> (Die <a href="DGzRS" class="mw-redirect" title="DGzRS">DGzRS</a> lässt in die neue Generation ihrer Seenotrettungskreuzer Bus-Systeme einbauen.)</li>

<li><a href="Pyrotechnik" title="Pyrotechnik">Pyrotechnik</a> (Vernetzung von Zündsystemen)</li>

<li><a href="Landtechnik" title="Landtechnik">Agrartechnik</a> (Vernetzung unterschiedlicher Steuergeräte, Sensoreinheiten und Aktoreinheiten)</li>

<li><a href="Informationssicherheit" title="Informationssicherheit">Sicherheitstechnik</a> (Vernetzung intern in Anlagen, extern bei einzelnen Bauelementen)</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Höhere_Protokolle"><span id="H.C3.B6here_Protokolle"></span>Höhere Protokolle</h2></div>

<p><a href="ISO_15765-2" title="ISO 15765-2">ISO 15765-2</a>, auch kurz <b>ISO-TP</b> ermöglicht den Transport von Botschaften, deren Länge die maximal 8 Bytes Nutzdaten eines CAN-<a href="Datenframe" title="Datenframe">Frames</a> überschreiten. Im <a href="OSI-Modell" title="OSI-Modell">OSI-Modell</a> deckt es die Schichten 3 (Network Layer) und 4 (Transport Layer) ab und kann bis zu 4095 Bytes Nutzdaten pro Telegramm transportieren. ISO-TP segmentiert längere Botschaften auf mehrere Frames und ergänzt die Datenpakete um Metadaten, die eine Interpretation der einzelnen Frames durch den Empfänger ermöglichen.

</p>

<div class="mw-heading mw-heading3"><h3 id="CANopen">CANopen</h3></div>

<p><i><a href="CANopen" title="CANopen">CANopen</a></i> ist ein auf CAN basierendes <a href="OSI-Modell" title="OSI-Modell">Schicht-7-Kommunikationsprotokoll</a>, welches anfänglich in der <a href="Automatisierungstechnik" title="Automatisierungstechnik">Automatisierungstechnik</a> verwendet wurde, mittlerweile aber vorwiegend in Embedded Systemen eingesetzt wird.

</p><p>CANopen wurde vorwiegend von deutschen klein- und mittelständischen Firmen initiiert und im Rahmen eines ESPRIT-Projektes unter Leitung von Bosch erarbeitet. Seit 1995 wird es von der <i><a href="CAN_in_Automation" title="CAN in Automation">CAN in Automation</a></i> gepflegt und ist inzwischen als Europäische Norm EN 50325-4 standardisiert. Der Einsatz erfolgt vorwiegend in Europa, gefolgt von Asien.

</p>

<div class="mw-heading mw-heading3"><h3 id="DeviceNet">DeviceNet</h3></div>

<p><i><a href="DeviceNet" title="DeviceNet">DeviceNet</a></i> ist ein auf CAN basierendes <a href="OSI-Modell" title="OSI-Modell">Schicht-7-Kommunikationsprotokoll</a>, welches hauptsächlich in der <a href="Automatisierungstechnik" title="Automatisierungstechnik">Automatisierungstechnik</a> verwendet wird.

</p><p>DeviceNet ist vorwiegend in Amerika verbreitet. Es wurde von <a href="Allen-Bradley" title="Allen-Bradley">Allen-Bradley</a> (gehört zu <a href="Rockwell_Automation" title="Rockwell Automation">Rockwell Automation</a>) entwickelt und später als offener Standard an die <i>ODVA</i> (Open DeviceNet Vendor Association) übergeben.

</p>

<div class="mw-heading mw-heading3"><h3 id="J1939_sowie_die_Erweiterungen_NMEA2000_und_ISOBUS">J1939 sowie die Erweiterungen NMEA2000 und ISOBUS</h3></div>

<p><a href="J1939" class="mw-redirect" title="J1939">J1939</a> ist ein auf CAN basierendes Protokoll im Nutzfahrzeugbereich. Es wird von der <a href="Society_of_Automotive_Engineers" class="mw-redirect" title="Society of Automotive Engineers">Society of Automotive Engineers</a> (SAE) gepflegt. Eine Einführung in J1939 findet sich in <i>Application Note Introduction J1939</i><sup id="cite_ref-9" class="reference"><a href="#cite_note-9"><span class="cite-bracket">[</span>9<span class="cite-bracket">]</span></a></sup>

</p><p><a href="NMEA_2000" title="NMEA 2000">NMEA 2000</a> ist eine Erweiterung von SAE J1939 für den maritimen Bereich. Das Protokoll der <a href="National_Marine_Electronics_Association" title="National Marine Electronics Association">NMEA-Organisation</a> breitet sich zunehmend aus. Vorgänger ist <a href="NMEA_0183" title="NMEA 0183">NMEA 0183</a>. NMEA2000 ist ein IEC-Standard: IEC61162-3.

</p><p>In der Landwirtschaft und Kommunaltechnik kommt der <a href="ISOBUS" title="ISOBUS">ISOBUS</a> (ISO 11783), der eine Erweiterung des J1939 darstellt, zur Steuerung und Überwachung von Anbaugeräten zum Einsatz.

</p>

<div class="mw-heading mw-heading3"><h3 id="CleANopen">CleANopen</h3></div>

<p>Eine Arbeitsgruppe der <i><a href="CAN_in_Automation" title="CAN in Automation">CAN in Automation</a></i>, die CANopen Special Interest Group (SIG) „Municipal Vehicles“, entwickelt das CANopen-Anwendungsprofil für Abfallsammelfahrzeuge: CleANopen (DIN EN 50325-4).

</p>

<div class="mw-heading mw-heading3"><h3 id="CANopen-Lift">CANopen-Lift</h3></div>

<p>Eine 2001 gegründete Arbeitsgruppe der <i><a href="CAN_in_Automation" title="CAN in Automation">CAN in Automation</a></i>, die CANopen Special Interest Group (SIG) „Lift Control“, entwickelt das CANopen-Anwendungsprofil (CANopen CiA-417) für <a href="Aufzugsanlage" title="Aufzugsanlage">Aufzüge</a>. Die erste Version von CiA 417 wurde im Sommer 2003 veröffentlicht. Die Version 2.0 steht seit Februar 2010 auf der CiA-Webseite frei zur Verfügung. Die Arbeitsgruppe arbeitet an der Erweiterung des CANopen-Lift-Funktionsumfangs, verfeinert technische Inhalte und sorgt um die Einhaltung aktueller, gesetzlich vorgeschriebener Normen für Aufzüge in CiA-417. Die Version 2.1.0 ist im Juli 2012 und die Version 2.2.0 (verfügbar für CiA-Mitglieder) ist im Dezember 2015 als Draft Standard Proposal verabschiedet worden. Im Jahre 2016 wurde an der Version 2.3.0 (verfügbar für CiA-Mitglieder) gearbeitet.

</p><p>Jörg Hellmich (ELFIN GmbH) ist der Vorsitzende dieser Arbeitsgruppe und betreibt unabhängig vom CiA ein Wiki der CANopen-Lift-Anwendergemeinschaft mit Inhalten zu CANopen Lift.

</p>

<div class="mw-heading mw-heading3"><h3 id="SafetyBUS_p">SafetyBUS p</h3></div>

<p><b><a href="SafetyBUS_p" title="SafetyBUS p">SafetyBUS p</a></b> ist ein auf CAN basierendes sicheres Kommunikationsprotokoll, welches hauptsächlich in der <a href="Automatisierungstechnik" title="Automatisierungstechnik">Automatisierungstechnik</a> zur Übertragung sicherheitsgerichteter Daten verwendet wird. Alle Busteilnehmer sind zwei- oder sogar dreikanalig aufgebaut und prüfen die Datenintegrität. Das Übertragungsmedium selbst ist nicht sicher, die Sicherheit wird durch das <i>SafetyBUS p</i>-eigene Datenprotokoll erreicht. Der <i>SafetyBUS p</i> kann bis <a href="Sicherheitsanforderungsstufe" title="Sicherheitsanforderungsstufe">SIL3</a> eingesetzt werden.

</p>

<div class="mw-heading mw-heading3"><h3 id="TTCAN">TTCAN</h3></div>

<p><i>Time-Triggered Communication on CAN</i> setzt auf dem CAN-Bus auf und ermöglicht über höhere Protokollebenen eine Echtzeitsteuerung. TTCAN ist in ISO 11898-4 genormt.

</p>

<div class="mw-heading mw-heading3"><h3 id="CANaerospace">CANaerospace</h3></div>

<p><a href="CANaerospace" title="CANaerospace">CANaerospace</a> ist ein <a href="Open_Source" title="Open Source">Open-Source</a>-Kommunikationsprotokoll, welches 1998 insbesondere für den Einsatz in der Luftfahrt mit ihren besonderen Zuverlässigkeits- und Leistungsanforderungen konzipiert wurde. Im Jahr 2000 hat die amerikanische <a href="NASA" title="NASA">NASA</a> CANaerospace als eigenen Standard übernommen. CANaerospace wird in zahlreichen Forschungsflugzeugen weltweit eingesetzt und hat sich als De-facto-Standard in der militärischen Flugsimulationstechnik etabliert.

</p>

<div class="mw-heading mw-heading3"><h3 id="ARINC_825">ARINC 825</h3></div>

<p><a href="ARINC_825" title="ARINC 825">ARINC 825</a> ist ein internationaler Luftfahrt-Kommunikationsstandard, welcher in einer Technischen Arbeitsgruppe (bestehend aus mehreren <a href="Luftfahrtunternehmen" title="Luftfahrtunternehmen">Luftfahrtunternehmen</a>, darunter <a href="Boeing" title="Boeing">Boeing</a> und <a href="Airbus" title="Airbus">Airbus</a>) auf der Basis von CANaerospace entwickelt wurde.

</p>

<div class="mw-heading mw-heading3"><h3 id="EnergyBus">EnergyBus</h3></div>

<p><a href="EnergyBus" title="EnergyBus">EnergyBus</a> ist ein Kommunikations- und Energieübertragungs-Bus und dazugehöriges Steckersystem für Leicht-<a href="Elektrofahrzeug" title="Elektrofahrzeug">Elektrofahrzeuge</a> wie Pedelecs und E-Bikes. EnergyBus wird von einem eingetragenen Verein, dem EnergyBus e. V. mit Sitz in Tanna gemeinsam mit dem CAN in Automation e. V. spezifiziert. Mitglieder sind sowohl Einzelpersonen wie auch Hersteller von Steckern, Batterien, Steuerungen und Antriebseinheiten (darunter <a href="Robert_Bosch_GmbH" title="Robert Bosch GmbH">Bosch</a>, <a href="Panasonic" class="mw-redirect" title="Panasonic">Panasonic</a>, <a href="Sanyo" title="Sanyo">Sanyo</a>, <a href="Deutsche_Bahn_AG" class="mw-redirect" title="Deutsche Bahn AG">Deutsche Bahn AG</a>, <a href="Philips" title="Philips">Philips</a> und <a href="VARTA" class="mw-redirect" title="VARTA">Varta</a>).<sup id="cite_ref-10" class="reference"><a href="#cite_note-10"><span class="cite-bracket">[</span>10<span class="cite-bracket">]</span></a></sup>

</p><p>Das Kommunikationsprotokoll ist im CANopen-Applikationsprofil 454 „energy management systems“ definiert.

</p>

<div class="mw-heading mw-heading3"><h3 id="FireCAN">FireCAN</h3></div>

<p>FireCAN wurde durch Zusammenarbeit österreichischer und deutscher Feuerwehraufbauhersteller im Jahr 2006 gegründet und ist mittlerweile als Norm DIN 14700 vorhanden. Ursprünglich wurde FireCAN als freie Übereinkunft der wesentlichen am Markt befindlichen Hersteller, die redaktionelle Betreuung der gemeinsamen Spezifikation wird dabei durch die Firma <a href="Rosenbauer_(Unternehmen)" title="Rosenbauer (Unternehmen)">Rosenbauer</a> ausgeübt. Die Vorstellung erfolgte im Zuge der <a href="DIN" class="mw-redirect" title="DIN">DIN</a>-Sitzung des Ausschusses NA 031-02-02 AA „Elektrische Betriebsmittel“ am 29. Oktober 2009 in <a href="Berlin" title="Berlin">Berlin</a>. Diese Datenbusfestlegung basiert auf einem vereinfachten <a href="CANopen" title="CANopen">CANopen</a>-Standard und regelt sowohl die physischen Eigenschaften (Stecker, Leitungen, Anschlussbelegung), die Art und Anzahl der Teilnehmer, sowie die verwendeten Datenformate und Dateninhalte. Als wesentlicher Vorgänger ist der in der Landwirtschaft erfolgreich eingeführte <a href="ISOBUS" title="ISOBUS">ISOBUS</a> zu verstehen.<sup id="cite_ref-11" class="reference"><a href="#cite_note-11"><span class="cite-bracket">[</span>11<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading3"><h3 id="Unified_Diagnostic_Services">Unified Diagnostic Services</h3></div>

<p>In <a href="Personenkraftwagen" title="Personenkraftwagen">Personenkraftwagen</a> sehr verbreitet ist mittlerweile <a href="Unified_Diagnostic_Services" title="Unified Diagnostic Services">Unified Diagnostic Services</a> gemäß der ISO 14229. In älteren Modellen verwendeten viele Hersteller eigene Standards, oft basierend auf der letztlich nicht standardisierten Norm für <a href="KWP2000" title="KWP2000">KWP</a> on CAN (Normentwurf ISO/DIS 15765).

</p>

<div class="mw-heading mw-heading2"><h2 id="Siehe_auch">Siehe auch</h2></div>

<ul><li><a href="FlexRay" title="FlexRay">FlexRay</a></li>

<li><a href="Local_Interconnect_Network" title="Local Interconnect Network">Local Interconnect Network</a> (LIN)</li>

<li><a href="SocketCAN" title="SocketCAN">SocketCAN</a> CAN-Treiber und Netzwerkschicht innerhalb des Linux-Kernels</li>

<li><a href="Can4linux" title="Can4linux">can4linux</a></li></ul>

<div class="mw-heading mw-heading2"><h2 id="Literatur">Literatur</h2></div>

<ul><li>Eine Liste über veröffentlichte CAN-Bücher<sup id="cite_ref-12" class="reference"><a href="#cite_note-12"><span class="cite-bracket">[</span>12<span class="cite-bracket">]</span></a></sup>, ist auf der Webseite des CiA zu finden.</li>

<li>Wolfhard Lawrenz (Hrsg.): <i>CAN Controller Area Network – Grundlagen und Praxis.</i>, 5. Auflage, VDE, Berlin/Offenbach 2011, ISBN 978-3-8007-3332-3.</li>

<li>Konrad Etschberger (Hrsg.): <i>CAN Controller Area Network – Grundlagen, Protokolle, Bausteine, Anwendungen.</i> Hanser, München 1994, ISBN 3-446-19431-2.</li>

<li>Horst Engels: <i>CAN-Bus – Technik einfach, anschaulich und praxisnah vorgestellt.</i> Franzis, Poing 2002, ISBN 3-7723-5146-8.</li>

<li>Werner Zimmermann und Ralf Schmidgall: <i>Bussysteme in der Fahrzeugtechnik – Protokolle, Standards und Softwarearchitektur.</i> 5. Auflage, Springer Vieweg, Wiesbaden 2014, ISBN 978-3-658-02418-5.</li>

<li>Kai Borgeest: <i>Elektronik in der Fahrzeugtechnik.</i> 3. Auflage, Springer-Vieweg, Wiesbaden 2013, ISBN 978-3-8348-1642-9.</li>

<li>Konrad Reif: <i>Batterien, Bordnetze und Vernetzung.</i> Vieweg + Teubner Verlag, Wiesbaden 2010, ISBN 978-3-8348-1310-7.</li>

<li>Gerhard Schnell und Bernhard Wiedemann: <i>Bussysteme in der Automatisierungs- und Prozesstechnik. Vieweg + Teubner Verlag,</i> Wiesbaden 2008, ISBN 978-3-8348-0425-9.</li>

<li>Mathias Rausch: <i>Kommunikationssysteme im Automobil</i> <i>– LIN, CAN, CAN FD, CAN XL, FlexRay, Automotive Ethernet</i>. Hanser, München 2022, ISBN 978-3-446-47035-4.</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Weblinks">Weblinks</h2></div>

<div class="sisterproject" style="margin:0.1em 0 0 0;"><div class="noresize noviewer" style="display:inline-block; line-height:10px; min-width:1.6em; text-align:center;" aria-hidden="true" role="presentation"><span class="mw-default-size" typeof="mw:File"><span title="Commons"></span></span></div><b><span class=""><a class="external text" href="https://commons.wikimedia.org/wiki/Category:CAN_bus?uselang=de"><span lang="en">Commons</span>: Controller Area Network</a></span></b> – Sammlung von Bildern, Videos und Audiodateien</div>

<ul><li><a rel="nofollow" class="external text" href="https://www.can-cia.org/can-knowledge/">Firmenneutrale Einführung der CiA in den CAN-Bus</a></li>

<li><a rel="nofollow" class="external text" href="https://elearning.vector.com/mod/page/view.php?id=111">Einführung in den CAN-Bus von VECTOR</a></li>

<li><a rel="nofollow" class="external text" href="http://www.canlist.org/">Unabhängige Diskussionsplattform CANLIST</a></li>

<li><a rel="nofollow" class="external text" href="http://www.can-wiki.info/">Wiki zur CAN-Technologie und Produkten</a></li>

<li><a rel="nofollow" class="external text" href="https://de.canopen-lift.org/">CANopen-Lift.org</a> Wiki der CANopen-Lift Community</li>

<li><a rel="nofollow" class="external text" href="https://www.youtube.com/watch?v=Ld1Bn4oDktg">Einführung in die CAN-Bus-Grundlagen anhand eines Modell-Autos (CANBASIC) mit CAN-Bus</a></li>

<li><a rel="nofollow" class="external text" href="https://www.kvaser.com/about-can/the-can-protocol/">CAN-Protokoll-Tutorial</a> (engl.)</li>

<li><a rel="nofollow" class="external text" href="http://www.microcontrol-blog.net/2012/12/fehlersuche-in-can-netzwerken/">Fehlersuche in CAN Netzwerken</a></li></ul>

<div class="mw-heading mw-heading2"><h2 id="Einzelnachweise">Einzelnachweise</h2></div>

<li id="cite_note-1"><span class="mw-cite-backlink"><a href="#cite_ref-1">↑</a></span> <span class="reference-text">Giuseppe Buja, Juan R. Pimentel, Alberto Zuccollo: <i>Overcoming Babbling-Idiot Failures in the FlexCAN Architecture. A Simple Bus-Guardian.</i> In: <i> Emerging Technologies and Factory Automation.</i> 2005, ISBN 0-7803-9401-1, S. 461–468 (<a rel="nofollow" class="external text" href="http://pdf.aminer.org/000/565/008/an_analysable_bus_guardian_for_event_triggered_communication.pdf">PDF-Datei</a>).</span>

</li>

<li id="cite_note-2"><span class="mw-cite-backlink"><a href="#cite_ref-2">↑</a></span> <span class="reference-text"><span class="cite">Pat Richards: <a rel="nofollow" class="external text" href="https://ww1.microchip.com/downloads/en/AppNotes/00754.pdf"><i>Understanding Microchip’s CAN Module Bit Timing.</i></a> In: <i>michrochip.com.</i> Microchip Technology Inc., 2001,<span class="Abrufdatum"> abgerufen am 3. Mai 2023</span> (englisch).</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3AController+Area+Network&rft.title=Understanding+Microchip%E2%80%99s+CAN+Module+Bit+Timing&rft.description=Understanding+Microchip%E2%80%99s+CAN+Module+Bit+Timing&rft.identifier=https%3A%2F%2Fww1.microchip.com%2Fdownloads%2Fen%2FAppNotes%2F00754.pdf&rft.creator=Pat+Richards&rft.publisher=Microchip+Technology+Inc.&rft.date=2001&rft.language=en"> </span></span>

</li>

<li id="cite_note-:0-3"><span class="mw-cite-backlink">↑ <sup><a href="#cite_ref-:0_3-0">a</a></sup> <sup><a href="#cite_ref-:0_3-1">b</a></sup></span> <span class="reference-text"><span class="cite">Ken Tindell: <a rel="nofollow" class="external text" href="https://canislabs.com/downloads/2020-02-14-White-Paper-CAN-Security.pdf"><i>CAN Bus Security.</i></a> In: <i>Canis Automotive Labs.</i> Canis Automotive Labs, 14. Februar 2020,<span class="Abrufdatum"> abgerufen am 19. Mai 2023</span> (englisch).</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3AController+Area+Network&rft.title=CAN+Bus+Security&rft.description=CAN+Bus+Security&rft.identifier=https%3A%2F%2Fcanislabs.com%2Fdownloads%2F2020-02-14-White-Paper-CAN-Security.pdf&rft.creator=Ken+Tindell&rft.publisher=Canis+Automotive+Labs&rft.date=2020-02-14&rft.language=en"> </span></span>

</li>

<li id="cite_note-:1-4"><span class="mw-cite-backlink">↑ <sup><a href="#cite_ref-:1_4-0">a</a></sup> <sup><a href="#cite_ref-:1_4-1">b</a></sup></span> <span class="reference-text">MILLER, Charlie; VALASEK, Chris. Remote exploitation of an unaltered passenger vehicle. <i>Black Hat USA</i>, 2015, 2015. Jg., Nr. S 91, S. 1–91.</span>

</li>

<li id="cite_note-:2-5"><span class="mw-cite-backlink">↑ <sup><a href="#cite_ref-:2_5-0">a</a></sup> <sup><a href="#cite_ref-:2_5-1">b</a></sup> <sup><a href="#cite_ref-:2_5-2">c</a></sup></span> <span class="reference-text">Mehmet Bozdal, Mohammad Samie, Sohaib Aslam, Ian Jennions: <cite style="font-style:italic">Evaluation of CAN Bus Security Challenges</cite>. In: <cite style="font-style:italic">Sensors</cite>. <span style="white-space:nowrap">Band<span style="display:inline-block;width:.2em"> </span>20</span>, <span style="white-space:nowrap">Nr.<span style="display:inline-block;width:.2em"> </span>8</span>, Januar 2020, <a href="Internationale_Standardnummer_f%C3%BCr_fortlaufende_Sammelwerke" title="Internationale Standardnummer für fortlaufende Sammelwerke">ISSN</a> <span style="white-space:nowrap"><a rel="nofollow" class="external text" href="https://zdb-katalog.de/list.xhtml?t=iss%3D%221424-8220%22&key=cql">1424-8220</a></span>, <span style="white-space:nowrap">S.<span style="display:inline-block;width:.2em"> </span>2364</span>, <a href="Digital_Object_Identifier" title="Digital Object Identifier">doi</a>:<span class="uri-handle" style="white-space:nowrap"><a rel="nofollow" class="external text" href="https://doi.org/10.3390/s20082364">10.3390/s20082364</a></span> (<a rel="nofollow" class="external text" href="https://www.mdpi.com/1424-8220/20/8/2364">mdpi.com</a> [abgerufen am 19. Mai 2023]).<span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rfr_id=info:sid/de.wikipedia.org:Controller+Area+Network&rft.atitle=Evaluation+of+CAN+Bus+Security+Challenges&rft.au=Mehmet+Bozdal%2C+Mohammad+Samie%2C+Sohaib+Aslam%2C+...&rft.date=2020-01&rft.doi=10.3390%2Fs20082364&rft.genre=journal&rft.issn=1424-8220&rft.issue=8&rft.jtitle=Sensors&rft.pages=2364&rft.volume=20" style="display:none"> </span></span>

</li>

<span class="cite"><a rel="nofollow" class="external text" href="https://web.archive.org/web/20161213073159/http://www.bosch-semiconductors.de:80/media/ubk_semiconductors/pdf_1/ipmodules_1/can_fd/icc13_2012_paper_Hartwich.pdf"><i>13. iCC Conference Paper.</i></a> (PDF; 215 KiB) Archiviert vom <style data-mw-deduplicate="TemplateStyles:r250917974">

/* start https://de.wikipedia.org/ */

.mw-parser-output .dewiki-iconexternal>a{background-position:center right!important;background-repeat:no-repeat!important}body.skin-minerva .mw-parser-output .dewiki-iconexternal>a{background-image:url("./_mw_/OOjs_UI_icon_external-link-ltr-progressive.svg")!important;background-size:10px!important;padding-right:13px!important}body.skin-timeless .mw-parser-output .dewiki-iconexternal>a,body.skin-monobook .mw-parser-output .dewiki-iconexternal>a{background-image:url("./_mw_/MediaWiki_external_link_icon.svg")!important;padding-right:13px!important}body.skin-vector .mw-parser-output .dewiki-iconexternal>a{background-image:url("./_mw_/Link.ernal-small-ltr-progressive.svg")!important;background-size:0.857em!important;padding-right:1em!important}

/* end https://de.wikipedia.org/ */

</style><span class="dewiki-iconexternal"><a class="external text" href="https://redirecter.toolforge.org/?url=http%3A%2F%2Fwww.bosch-semiconductors.de%3A80%2Fmedia%2Fubk_semiconductors%2Fpdf_1%2Fipmodules_1%2Fcan_fd%2Ficc13_2012_paper_Hartwich.pdf">Original</a></span> am <span style="white-space:nowrap;">13. Dezember 2016</span><span style="display:none">;</span><span class="Abrufdatum" style="display:none"> abgerufen am 17. Juni 2017</span>.</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3AController+Area+Network&rft.title=13.+iCC+Conference+Paper&rft.description=13.+iCC+Conference+Paper&rft.identifier=https%3A%2F%2Fweb.archive.org%2Fweb%2F20161213073159%2Fhttp%3A%2F%2Fwww.bosch-semiconductors.de%3A80%2Fmedia%2Fubk_semiconductors%2Fpdf_1%2Fipmodules_1%2Fcan_fd%2Ficc13_2012_paper_Hartwich.pdf&rft.source=http://www.bosch-semiconductors.de:80/media/ubk_semiconductors/pdf_1/ipmodules_1/can_fd/icc13_2012_paper_Hartwich.pdf"> </span></span>

</li>

<li id="cite_note-7"><span class="mw-cite-backlink"><a href="#cite_ref-7">↑</a></span> <span class="reference-text"><span class="cite"><a rel="nofollow" class="external text" href="https://web.archive.org/web/20170702153246/http://www.bosch-semiconductors.de/media/automotive_electronics/pdf_2/ipmodules_3/can_fd_1/icc14_2013_paper_Hartwich.pdf"><i>CAN FD Specification Version 1.0.</i></a> (PDF; 313 KiB) Archiviert vom <span class="dewiki-iconexternal"><a class="external text" href="https://redirecter.toolforge.org/?url=http%3A%2F%2Fwww.bosch-semiconductors.de%2Fmedia%2Fautomotive_electronics%2Fpdf_2%2Fipmodules_3%2Fcan_fd_1%2Ficc14_2013_paper_Hartwich.pdf">Original</a></span> am <span style="white-space:nowrap;">2. Juli 2017</span><span style="display:none">;</span><span class="Abrufdatum" style="display:none"> abgerufen am 20. Juni 2017</span>.</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3AController+Area+Network&rft.title=CAN+FD+Specification+Version+1.0&rft.description=CAN+FD+Specification+Version+1.0&rft.identifier=https%3A%2F%2Fweb.archive.org%2Fweb%2F20170702153246%2Fhttp%3A%2F%2Fwww.bosch-semiconductors.de%2Fmedia%2Fautomotive_electronics%2Fpdf_2%2Fipmodules_3%2Fcan_fd_1%2Ficc14_2013_paper_Hartwich.pdf&rft.source=http://www.bosch-semiconductors.de/media/automotive_electronics/pdf_2/ipmodules_3/can_fd_1/icc14_2013_paper_Hartwich.pdf"> </span></span>

</li>

<li id="cite_note-8"><span class="mw-cite-backlink"><a href="#cite_ref-8">↑</a></span> <span class="reference-text"><a rel="nofollow" class="external free" href="https://www.can-cia.org/can-knowledge/">https://www.can-cia.org/can-knowledge/</a></span>

</li>

<li id="cite_note-9"><span class="mw-cite-backlink"><a href="#cite_ref-9">↑</a></span> <span class="reference-text"><i><a rel="nofollow" class="external text" href="https://cdn.vector.com/cms/content/know-how/_application-notes/AN-ION-1-3100_Introduction_to_J1939.pdf">Eine Protokolleinführung: </a></i><a rel="nofollow" class="external text" href="https://cdn.vector.com/cms/content/know-how/_application-notes/AN-ION-1-3100_Introduction_to_J1939.pdf">Application Note Introduction J1939<i></i></a><i> (PDF; 284 kB)</i></span>

</li>

<li id="cite_note-10"><span class="mw-cite-backlink"><a href="#cite_ref-10">↑</a></span> <span class="reference-text"><span class="cite"><a rel="nofollow" class="external text" href="https://energybus.org/energybus-members"><i>The EnergyBus e. V. members.</i></a> EnergyBus,<span class="Abrufdatum"> abgerufen am 14. November 2023</span> (englisch).</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3AController+Area+Network&rft.title=The+EnergyBus+e.%26nbsp%3BV.+members&rft.description=The+EnergyBus+e.%26nbsp%3BV.+members&rft.identifier=https%3A%2F%2Fenergybus.org%2Fenergybus-members&rft.publisher=EnergyBus&rft.language=en"> </span></span>

</li>

/* start https://de.wikipedia.org/ */

.mw-parser-output .webarchiv-memento a{color:inherit}

/* end https://de.wikipedia.org/ */

</style><a rel="nofollow" class="external text" href="https://web.archive.org/web/20160304091232/http://www.firecan.info/Default.aspx">(alte) Webseite FireCAN</a> (<span class="webarchiv-memento"><a href="Webarchivierung#Begrifflichkeiten" title="Webarchivierung">Memento</a></span> vom 4. März 2016 im <i><a href="Internet_Archive" title="Internet Archive">Internet Archive</a></i>)</span>

</li>

<li id="cite_note-12"><span class="mw-cite-backlink"><a href="#cite_ref-12">↑</a></span> <span class="reference-text"><span class="cite"><a rel="nofollow" class="external text" href="https://can-newsletter.org/engineering/engineering-miscellaneous/nr_e_cia_can_books_120529"><i>Liste mit veröffentlichten CAN-Büchern.</i></a> In: <i>can-newsletter.org.</i><span class="Abrufdatum"> Abgerufen am 24. August 2016</span>.</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3AController+Area+Network&rft.title=Liste+mit+ver%C3%B6ffentlichten+CAN-B%C3%BCchern&rft.description=Liste+mit+ver%C3%B6ffentlichten+CAN-B%C3%BCchern&rft.identifier=https%3A%2F%2Fcan-newsletter.org%2Fengineering%2Fengineering-miscellaneous%2Fnr_e_cia_can_books_120529&rft.date="> </span></span>

</li>

</ol>

<div>

Normdaten (Sachbegriff): <a href="Gemeinsame_Normdatei" title="Gemeinsame Normdatei">GND</a>: <span class="-print"><a rel="nofollow" class="external text" href="https://d-nb.info/gnd/4338572-2">4338572-2</a></span> </div>

</div></div></div><div><div class="zim-footer">

Dieser Artikel wurde von <a class="external text" title="Zuletzt bearbeitet am 2025-12-17" href="https://de.wikipedia.org/wiki/?title=Controller_Area_Network&oldid=262501409">Wikipedia</a> herausgegeben. Der Text ist unter <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.de">Creative Commons Attribution-Share Alike 4.0</a> verfügbar, sofern nicht anders angegeben. Für die Mediendateien können zusätzliche Bedingungen gelten.

</div>

</div></div>

</div>

</main>

</div>

</body></html>